1. Field
Embodiments of the present invention relate generally to design templates and, more particularly, to replacing data in structured design templates.
2. Description of the Related Art
Being able to represent structured data in complex graphical representations can help businesses and organizations to identify successes, failures, trends, and opportunities for greater effectiveness. Reports, which may include data grids, charts, pictures, maps, and other data and non-data driven sections, are the most common way to represent and facilitate analysis of data.
A geographical map is a non-limiting example of such a report. Many examples put forth herein concern maps. However, the same concepts are applicable to all software that can create reusable design templates, through which data may be visualized or analyzed.
To give a richer context, let us consider the following examples which describe the benefits of representing data on a geographical map. Regarding business and public interest, examples may include: highlighting sales by geographic region; tracking marketing spending and effectiveness by geography; visualizing theft by geography; correlating data, such as weather or demographics, with sales; and visualizing data geographically over time, such as the spread of contaminants, disease, changing personal preferences, or sales. Regarding politics, examples may include: visualizing constituents by affinity, and/or by geography; showing voter turnout and election results by political jurisdiction; and displaying get out the vote (GOTV) efforts and activities.
There are many ways to show data on a map. For instance, one can represent sales in a particular geography by a semi-transparent round circle, whose size depends on the amount of sales. If the map is presented interactively, it may be possible to “drill” into the map by clicking on a geographical region or a zoom tool of some kind. Drilling may refresh the map, thereby showing other data. For instance, a more detailed breakdown of sales in that geographical region, denoted by color coding zip codes or pictographs such as dollar signs may be shown on the map. Other examples of additional data that may be displayed include text overlays showing monetary amounts in various colors and labels or annotations based on data-driven rules or other logic. For example, if sales were greater than $10,000, the actual amount of sales could be written on a circle in small blue print, rounded to the nearest thousand and represented using a dollar sign.
There are different ways to represent data, and creating sophisticated representations such as maps typically may require learning and using different software tools in different situations, such as different job environments. In addition, creating complex representations such as maps may often require formatting data in very specific ways and placing it in special data providers so that the mapping software can access the data properly.
Such representations are typically created in sophisticated tools that permit a high degree of control over fonts, layouts, colors, data, etc. They may permit scripting or even compiled code and require varying levels of training and expertise. They are typically built by an expert and updated periodically as required. They may be very sophisticated and difficult to perfect—sometimes even created and tested in one environment, and then deployed to another. The amount of knowledge and time required to format and properly situate the data, configure, and define rules for rendering the data using such tools may be prohibitive for most non-technical and business users for whom “reporting” is not a primary job function. As such, the graphical template design function may often be performed by an expert or power user.
Tools designed for this purpose are continually evolving. Applications such as Business Objects™ Xcelsius™ provide a graphical environment for adding data bound Adobe™ Flash™ components to a canvas. These components may be linked together creatively and bound to a Microsoft™ Excel™ worksheet as a design-time data source. At run-time, a high degree of user interaction is permitted and the components (“report”) can “pull” data from a wide variety of data sources or data from a wide variety of data sources can be “pushed” to the report. Other tools such as Business Objects™ Crystal Reports™, Business Objects™ WebIntelligence Reports™, and Cognos™ Report.Net™ are representative of the genre. However, a report may be also something more crude (without a graphical, design-time environment), such as a web-page programmed in a language like PHP.
How client end-users view and access data varies. In a “production reporting” scenario, client end-user is a consumer of a report created by a reporting export, as described. The client end-user explicitly invokes the report, which may or may not require parameterized inputs, to render it on-screen or to an output device like a printer. Alternatively, such a report is run by the system at certain intervals, in response to a system event, or through other means. In a typical workflow, the client's interaction with the report summarily ends after examining and/or printing the report. In these cases, the details concerning where and how data was fed to the report is not necessarily known by the report consumer.
Accessing reports in this manner is quite different from a “query and analysis” approach where the client end-user assumes control of the investigation. At a minimum, this investigation begins with running a production report—which could be a web page of any kind—but typically entails self-service analysis of the data using a tool like Microsoft™ Excel™ or Business Objects™ WebIntelligence™. In this scenario, the client end-user queries (or otherwise obtains) data and then manipulates it in various ways, eventually producing one or more data grids accompanied by simple graphical representations, like charts. Tools designed to facilitate this scenario often trade ease-of-use for advanced functionality including layout precision. In such a scenario, getting the right numbers, or high-level analysis, may be more important than pretty pictures or complex interactions. Moreover, to create new visualizations requires knowledge of the tool and additional end-user work. While it is often possible to create formulas, precise control of formatting, pixel-by-pixel, typically is not, or is sufficiently time-consuming that client end-users will not do it.
But what if a client end-user, staring at a grid of data in either a report or self-service investigative tool, wanted a pretty, pixel-perfect formatted version of it quickly—to see it (possibly contextualized with information from other sources) in a richly formatted Crystal Report™ or on a map? What if they wanted to allow complex interactions or representations that required the use of an authoring tool they could not or did not want to operate for a variety of reasons?
In a conventional approach, there is no acceptable solution to this quandary. Why? Because there is not an effective means to match and populate arbitrary client data with ready-built graphical templates (“reports”). Users would need to create the report themselves or queue up to have it created for them. Either way, time, money, and tempers may be exhausted.
However, if suitable templates did already exist and data could be shown on them easily, the quandary would be resolved. Instead of learning how to build fancy reports, client end-users would simply choose a suitable report template from a matched list presented to them by a report discovery and matching system.
Relevant related art falls into predominantly two categories: schemes that simplify creating visualizations (using templated visualizations) and schemes for showing data in templates generally. A desirable, robust framework, that effectively facilitates repurposing data from client applications to potentially complex reports, has not been developed.
In a conventional approach to data visualization, the client end-user is deeply involved in the creation of that visualization (ie. chart, table, report) process. In such a scenario, simplifying the process of creating such visualizations is the software design priority. Such systems are designed to do as much as possible, with as little user input as possible. For instance, highlighting a block of data on a spreadsheet and then clicking a chart icon may automatically create a chart that adjusts itself to accommodate the range of data values provided. Alternatively, a wizard may launch, walking the client end-user through a number of steps (some optional) before showing the visualization (ie. chart, map, table, report). The wizard may be “smart” but the burden of creating it is still on the client end-user and what is shown is limited by the client end-user's ability, time, and effort—as well as the software.
Along these lines, an approach is described in U.S. Pat. No. 6,529,217 issued to Maguire, III et al, which involves drag and drop graph creation. That is, Maguire relates to creating a graph using an interface containing icons representing data fields, templates including drop areas, and enhanced user feedback. In this instance, the graph is the template and the methodology makes it easier to create an instance of a graph.
Another approach is described in U.S. Patent Application Publication No. 2007/0016561 by Laustsen. The Laustsen approach relates to creating data reports using a tool that displays an overview of data to a user and allowing a user to select from available data to create a report.
Another conventional approach to show data more easily, is to explicitly map content records to display handler templates which format and beautify the data—for instance, as a web-page or a magazine article.
Another conventional approach is described in U.S. Patent Application Publication No. 2004/0181543 by Wu et al. The Wu application describes a possibly fixed universe of approximately 10 well-known “templates” that have limited rendering flexibility and serve the primary purpose of clarifying data content, relationships, and semantics. In the Wu system, browsing and binding data to these templates is part of an iterative process of data discovery designed to facilitate correct use of federated data. Although such an approach may be useful for “peeking at” or “profiling” data from different sources, it may not be useful for representing user data graphically for analysis.
In the related art, embodiments of the client end-user driven template creation process (ie. build a map from data in a Microsoft™ Excel™ worksheet) that also permit saving and reusing the graphical representation as a “template” that may be associated with the client data application and reused in some fashion were found. However, such embodiments proved to be critically limited. For instance, binding between the “template” and the client data source is primitive and explicit. Since client and template data are not analyzed prior to matching, incompatible templates could be presented invoked and may fail unexpectedly (since column names and data types do not match perfectly). Moreover, without a flexible and robust matching process, the universe of candidate templates is very small and thus, template reuse is critically limited.
In neither related art nor the marketplace, does a solution appear to exist that allows client end-users the flexibility to query, assemble, and analyze data in spreadsheets, reports, or other applications, and ALSO the ability to easily present that data on arbitrarily complex, pre-made templates. Accordingly, there is a need for a versatile method and system for representing data that is easy for an average user to use. There is also a need for a data-aware method and system that is useful for representing user data.